Cloud-based decisioning for addressable asset system

ABSTRACT

An addressable asset system ( 100 ) includes user equipment devices (UEDs) ( 102 ), a cloud decisioning system (CDS) ( 106 ) and a business data management system (BDMS) ( 108 ). The BDMS ( 108 ) collects information that is used by the CDS ( 106 ) to manage delivery of assets by the UEDs ( 102 ). In an exemplary network architecture, the CDS ( 106 ) is independent of the network insertion and delivery equipment. In particular, the broadcast content stream is delivered to the UED ( 102 ) by a digital content management (DCM) system ( 110 ) and certain assets are separately delivered to the UED ( 102 ) by the asset download network (AND) ( 112 ). This allows the CDS ( 106 ) to remain independent of the network of the UED ( 102 ) such that the CDS ( 106 ) can operate across networks.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. application Ser. No.16/932,042 entitled “MANAGING ADDRESSABLE ASSET CAMPAIGNS ACROSSMULTIPLE DEVICES,” and filed Jul. 17, 2020, which is a Continuation ofU.S. Pat. No. 10,735,795, entitled “MANAGING ADDRESSABLE ASSET CAMPAIGNSACROSS MULTIPLE DEVICES,” and issued on Aug. 4, 2020, the entirecontents of each of which are hereby incorporated within by reference.

FIELD OF THE INVENTION

The present invention relates generally to delivering addressable ortargeted assets to users of user equipment devices such as televisionsor streaming devices and, in particular, to managing and monitoringaddressable asset campaigns, including across multiple devices, multiplenetworks and/or multiple modalities.

BACKGROUND OF THE INVENTION

Asset providers, e.g., providers of advertisements, public serviceannouncements and other content, put considerable effort into the designof campaigns. Such campaigns are defined in relation to, among otherthings, where and how the asset will be delivered (e.g., what mediamodalities, in connection with what programming/other assets, etc.),when the asset will be delivered (e.g., during what time frame, at whattime-of-day, how frequently, how many total times) and to whom (e.g.,defined in relation to demographic segments, income, purchasingbehavior, lifestyles, interests, etc.). Over many years, these campaignshave been analyzed to optimize campaign effectiveness and manyprofessionals have devoted their careers to understanding the art andscience of campaign design.

For example, the process of developing a television advertising campaignmay begin by conducting extensive surveys and market studies to define atarget audience for a product or service to be advertised. Anadvertising agency may be retained to develop an advertisement or set ofadvertisements intended to produce the desired response from thetargeted audience. The advertisements may be tested on focus groups ortest markets and results analyzed. Additional studies and expertise maybe applied to determine how many times the advertisement needs to bepresented to the target audience for the message to be effectivelyconveyed, how many times would result in diminishing returns or becounterproductive, how should a set of related advertisements besequenced, what channels/programming yield useful associations or shouldbe avoided, etc.

Even after goals concerning delivery of impressions have been defined,considerable effort is needed to determine how to execute the campaign.Conventionally, in the case of television advertising, this has involvedcontracting to purchase “spots” in particular programming (anadvertising break in a program may have multiple spots for ad placement)or otherwise contract for delivery of some defined level ofdissemination. In this regard, the purchaser may consider ratingsinformation, other viewing statistics and research results, as well ascosts (e.g., cost per thousand viewers or CPM), campaign budget andsubjective considerations that inform the art of campaign design. Thecampaign may be modified during execution based on feedback, changedgoals or the like.

This considerable knowledge base is being impacted by developments inthe field that present evolving challenges and opportunities. Among themore significant developments in this regard are the emergence ofaddressable advertising and the evolution of media devices andconsumption patterns.

Addressable advertising relates to the ability to customize, at least tosome extent, the content stream delivered to individual network users,even in connection with broadcast programming. For example, it isbecoming increasingly common for different viewers watching the samebroadcast programming on the same channel in real-time to receivedifferent advertisements. The advertisements may be selected based ondetermined or estimated characteristics of the viewer, such asdemographic attributes or purchasing behavior and, in some cases, may behighly specific or even unique to that viewer. While this enablestargeting with fine granularity, it also entails a paradigm shift frombuying spots to buying impressions and erodes the experiential knowledgethat informs the art of campaign design.

This art is further impacted by the evolution of media devices andhabits of viewers. Increasingly, programming is being consumed usingDVRs, streaming devices (computers, tablets, televisions that can accessdata networks, phones, etc.) and other media devices and are not limitedto viewing real-time, linear broadcast programming. In some cases,network providers are marketing plans such as TV Anywhere plans thatenable and encourage consumption of broadcast television content at theconvenience of customers. While this enhances the experience for theconsumer, and expands potential advertising opportunities, it alsosignificantly complicates campaign design and execution. Among otherthings, some of those modalities enable skipping of assets (e.g.,fast-forwarding through or tuning/clicking away from assets) and themodalities generally complicate estimating and tracking viewership.

SUMMARY OF THE INVENTION

The present invention is directed to a system and associatedfunctionality for managing and monitoring the delivery of assets tonetwork users to comply with campaign specifications. A system isdisclosed for managing and monitoring asset delivery that is largelyindependent of content/asset delivery mechanisms. The system thusfacilitates management and monitoring of asset delivery with respect toa single device or multiple devices, including, multiple devices ofmultiple networks or modalities, e.g., a television, a laptop and atablet. The system therefore assists in designing and executingcampaigns by providing some assurance that users can be reached with adesired frequency using known modalities and that the desired totalnumber of impressions can be reasonably controlled. Asset providers canalso submit asset delivery requests for executing a campaign via asingle platform/process with a better understanding of costs and costrates. In this manner, existing knowledge and skills can be readilytranslated to this evolving marketplace even as new techniques aredeveloped to capitalize on new opportunities.

In accordance with one aspect of the invention, a system and associatedfunctionality is provided the enables coordinated control of assetdelivery across a managed set of user equipment devices (UEDs). The UEDscommunicate with an asset targeting system that has informationconcerning a set of assets that are available for scheduling fordelivery to particular users. For example, the system may be implementedin connection with one or more servers that communicate with the UEDsand other platforms at least in part via a pathway of a data network.The system receives an indication of an identified asset deliveryopportunity (ADO) (e.g., a product placement opportunity or advertisingbreak in real-time or linear programming or in streaming or non-linearprogramming) and transmits a playlist of one or more assets for the ADO.For example, the playlist may include a single asset to be played,multiple assets to be played in series, or multiple asset options fromwhich the device can select an asset or assets to play. In the latterregard, it will be appreciated that the device may optionally includelogic for making selections based on user demographics, location,monitored asset delivery (e.g., associated with the set of UEDs), etc.However, the inventive system can advantageously be implemented withoutrequiring any specialized equipment or logic on the user side.

The playlist can be based on user impression information and campaignspecification information for the first asset. For example, the userimpression information may include information concerning the times andcompleteness of previous deliveries of the asset to the user that can beused to monitor and manage frequency and pace of asset delivery andtotal number of impressions (e.g., one complete delivery of an asset, orsome defined consumption level less or more than a complete delivery, ordelivery combined with some other attribute indicative of presenceand/or engagement, may be defined as an impression). Such impressionsmay be aggregated over different devices, networks and modalities and/ortracked separately for different devices/networks/modalities. Thecampaign specification information relates to a desired level ofdissemination for the asset and may be based on an asset deliveryrequest entered on a contracting platform. For example, the assetdelivery request may include targeting constraints for the targetaudience and a desired audience size or campaign cost as well asspecifications concerning the frequency, total number of impressions,sequencing of assets, and the like for individual users.

For example, the playlist for a particular user or UED may be based inpart on a comparison of the user impression information to the campaignspecification information and potentially other considerations. Thus, ifa contracting party (e.g., an asset provider) specifies each targeteduser should receive a specified asset at least 10 but not more than 20times during a specified time period or date range, and specifies thatat least 8 of those impressions should be in connection with linearprogramming, and if the ADO is associated with linear programming andthe relevant user at that time needs additional linear impressionsbefore an impending expiration of a campaign, the asset may beprioritized for inclusion in the playlist. The system may also take intoaccount the value of delivery, the need to fulfill other campaigns andother considerations in generating the playlist.

The system can update the user impression information for the firstasset based on the UED playing the first asset. For example, the systemmay receive reports from servers or headend equipment involved intransmitting the asset and/or from UEDs that control playing of theasset. In either case, the reports may include an indication that theasset was played, the time that the asset was played, information aboutwhether the asset played in its entirety or that play was incomplete,and information indicating presence, interest, active engagement or thelike. In some contexts, such as certain broadcast network contexts, suchreports may most practically originate at least in part from the UED.The system may also obtain report information from retail outlets,credit agencies, advertisers or others concerning purchases, site visitsor other indications of engagement or effectiveness related to theasset. The reports can be obtained and the user impression informationcan be updated in substantially real-time (e.g., reports provided viathe internet) or periodically, thus enabling accurate and timely controlof campaign fulfillment parameters such as frequency and total number ofimpressions.

The assets may be delivered to the UED at playtime or ahead of playtimefor storage at the UED. For example, the system may instruct the UED tostore the asset at a storage structure associated with the UED or mayinstruct the UED to play an asset transmitted in real-time during theADO. Additionally or alternatively, the UED may indicate to the systemwhat assets are available for playing so that the system can use thatinformation to construct the playlist. The assets may be transmitted tothe UED by a platform associated with the system or separate therefrom,and may be controlled at least in part by the system or independentthereof.

In accordance with another aspect of the present invention, a system andassociated functionality are provided for monitoring consumption ofassets on one UED to select assets for delivery on another UED. Morespecifically, the functionality involves receiving an indication, for afirst UED of a set of UEDs of a user, that the first UED has played afirst asset of a set of assets. For example, as discussed above, a UEDor other platform may provide a report concerning asset delivery. Basedon the received indication, user impression information for the firstasset is updated and the updated impression information can be comparedto campaign specification information. For example, the campaignspecification information may specify a target of one or moreimpressions delivered to the user via the first UED. When the campaignspecification information is satisfied, a playlist may be transmitted,for a second UED of the set of UEDs, directing the play of a secondasset, the same as or different than the first asset, at a second,different UED of the set of UEDs. In this manner, for example, atelevision or set top box of a user may be directed to play a televisioncommercial after the user has received an image or stream advertisementvia the internet or vice versa.

In accordance with a further aspect of the present invention, a systemand associated methodology are provided that enable addressable assetdelivery independent of the architecture of the UED network. It will beappreciated that addressable asset delivery has generally beenconceptualized, heretofore, as a network function. This is, a systemembodied in a network platform, such as a broadcast television networkheadend, generally made decisions concerning asset delivery andcontrolled insertion equipment to effect delivery. Consequently, suchconventional systems had ready access to information concerning theassets available to be played on UEDs but little if any informationrelated to asset delivery to a given user via different UEDs.

The present aspect of the invention implements decisioning via anarchitecture that is more independent of the UED network and morereadily applicable across multiple devices, networks and modalities. Theassociated functionality involves instructing a UED to store assets ofan asset set at a memory structure of the UED (physically embodied inthe UED or otherwise accessible by the UED). For example, an assetdecisioning system may instruct the UED to store a set of assets thatare deemed likely to be selected for delivery based on a comparison ofasset targeting constraints to classification parameters associated withthe UED (e.g., demographic parameters, interests or purchasing behaviorof a user or users of the UED). The decisioning system then receives anindication of the assets stored at the memory structure and transmits aplaylist instructing the UED to deliver (e.g., play back) one or more ofthe assets at one or more ADOs. For example, the decisioning system mayconstruct the playlist taking into account information concerning thecurrent user or users (actual, estimated or estimated classificationparameters), campaign specifications for the assets, and user impressioninformation for the UED and/or other UEDs. In one implementation, thedecisioning system is cloud-based and can access delivery informationand/or control asset delivery across multiple devices, networks andmodalities.

It will be appreciated that the invention encompasses the overall systemand associated functionality as described herein as well as systemcomponents and corresponding functionality associated with eachcomponent or set of components, e.g., the node or nodes embodying thenetwork-side of the system, each of the set of UEDs or combinationthereof, servers or headend equipment, contracting platform, and otherplatforms involved in reporting asset consumption and/or associated userbehavior.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and furtheradvantages thereof, reference is now made to the following DetailedDescription, taken in conjunction with the drawings, in which:

FIG. 1 is a schematic diagram of an addressable asset system inaccordance with the present invention;

FIG. 2 is a schematic diagram of an alternative implementation of anaddressable asset system in accordance with the present invention;

FIG. 3 is a schematic diagram of a still further alternativeimplementation of an addressable asset system in accordance with thepresent invention;

FIG. 4 is a schematic diagram of a decisioning system in a multi-networkenvironment in accordance with the present invention; and

FIG. 5 is a flow chart summarizing a process for managing asset deliveryacross multiple devices, multiple networks and/or multiple modalities.

DETAILED DESCRIPTION

In the following description, the invention is primarily set forth inthe context of addressable asset systems for selecting and deliveringassets in television (broadcast, on-demand, streaming, etc.) and othernetworks. The assets may be, for example, video advertisements fordelivery during advertising breaks in broadcast (cable, satellite,over-the-air, etc.) programming, product placement in broadcastprogramming, advertisements for internet delivery (video, images, text,etc.), public service announcements, network announcements or othercontent.

The invention is described in relation to implementations where theasset decisioning system is independent of (is not dependent on) thecontent delivery systems and asset download systems of the network. Inaddition, in certain embodiments, the invention is described in relationto monitoring asset delivery and making asset delivery decisions inaddressable-asset environments involving multiple devices, multiplenetworks and/or multiple modalities. However, the invention is notlimited to such contexts, e.g., certain aspects of the invention areadvantageous even in the context of managing and monitoring assetdelivery for a single device, network and modality or in connection withasset decisioning systems that are integrated with or dependent on thenetwork delivery systems.

The invention is first described below in connection with a systemarchitecture including an independent asset decisioning system.Exemplary implementations for managing and monitoring multiple devicesin a single network are then described. Thereafter, a system isdescribed for managing and monitoring asset delivery in a multi-networkenvironment. Finally, a number of use cases for the inventive systemsare described.

I. Single Device

FIG. 1 illustrates an addressable asset system 100 in accordance withthe present invention that manages and monitors asset delivery withrespect to individual UEDs 102 although only one UED 102 is illustrated,and the management/monitoring functionality is implemented on a per UEDbasis, the network would generally include many UEDs. As will beunderstood from the description in the sections below, the invention isapplicable with respect to a variety of types of UEDs in variousnetworks utilizing various modalities. In the illustrated embodiment,the UEDs 102 are televisions, for example, associated with a cable orsatellite television network.

As will be understood from the description below, the UEDs 102 arecapable of receiving, decoding and displaying a selected band of abroadcast content stream (e.g., a digital stream including one or moreprogramming channels) and accessing a data platform to download assetfiles (e.g., digital media files) for storage in a storage unit 103 ofthe UED 102. The UED 102 may also be capable of accessing on-demand orstreaming video content from the broadcast network or a data networksuch as the internet. The UED 102 may thus be embodied in one or moremachines such as a smart television, a set top box, a DVR, an externalcomputer and/or an external storage device. The storage unit 103 mayinclude disk drives, solid state storage devices or other storagestructure. The UEDs 102 can deliver assets in connection with broadcast,on-demand and streaming programming with suitable adjustments, e.g., toidentify ADOs.

It will be appreciated that the ability to deliver addressable assets inconnection with broadcast networks is advantageous due to both the valueof asset delivery in these networks and the difficulty of deliveringaddressable assets in connection with the broadcast mode. Addressableasset systems generally allow for delivery of selected assets forindividual UEDs, users or groups of users based on classificationparameters of those users which may include, for example, demographicattributes; psychographic attributes; a present, residence, or otherlocation of a user; income, purchasing behavior or other financialinformation of a user; viewing, browsing or other network behavior;interests or other lifestyle factors; or other parameters of interest toan asset provider, network provider, sociologist, researcher, or otherinterested party. In some implementations, assets can be selected forindividual users based on matching targeting constraints and othercampaign specifications for an asset to classification parameters andimpression information of the user or UED.

However, it will be appreciated that the invention is not limited tosuch addressable asset contexts. For example, while executing decisionsfor asset delivery, e.g., to take into account campaign specificationssuch as frequency and total impression count, may involve device levelinsertion functionality, such execution does not necessarily entailmatching of classification parameters to corresponding asset targetingconstraints. Asset providers may desire that even untargeted assets aredelivered in accordance with certain campaign specifications, e.g.,related to frequency, overall impression count or sequencing of relatedassets.

Addressable asset delivery systems are described in the following U.S.patents and applications that are incorporated herein by reference:“U.S. patent application Ser. No. 09/877,718, entitled “TargetedImpression Model for Broadcast Network Asset Delivery,” (“the Invidi Iapplication”); “U.S. patent application Ser. No. 11/331,835, entitled“Targeted Impression Model for Broadcast Network Asset Delivery,” andnow issued as U.S. Pat. No. 8,108,895 (“the Invidi II application”);“U.S. patent application Ser. No. 14/949,442, entitled “TargetedImpression Model for Broadcast Network Asset Delivery” (“the Classifierapplication”); “U.S. patent application Ser. No. 12/024,696, entitled“Targeting Content Based on Location,” and now issued as U.S. Pat. No.8,850,473 (“the Location application”); U.S. patent application Ser. No.12/024,714, entitled “Compensating for Ad-skipping in a CommunicationsNetwork” (“the Asset Skipping application”); U.S. patent applicationSer. No. 12/467,890, entitled “Compensating for Ad-skipping in aCommunications Network,” and now issued as U.S. Pat. No. 8,146,126 (“theRequest for Information application”); U.S. patent application Ser. No.12/022,209, entitled “Asset Targeting System for Limited ResourceEnvironments,” and now issued as U.S. Pat. No. 7,849,477 (“the LimitedResource application”); U.S. patent application Ser. No. 13/870,870,entitled “Third Party Data Matching for Targeted Advertising,” (“theThird Party Data Matching application”); U.S. patent application Ser.No. 13/673,869, entitled “Targeted Advertising in Unicast, Multicast andHybrid Distribution System Contexts” (“the Multicast application”).While the present invention sets forth, among other things, alternatedecisioning systems, asset delivery networks and protocols, and assetmanagement and monitoring functionality, the above-noted patents andapplications disclose structure, functionality and considerations thatare relevant to the present invention. Those include, by way of example,subject matter related to identifying a current user or classificationparameters thereof, matching classification parameters to targetingconstraints, reporting delivery of assets, determining user presence andengagement, and identifying asset skip or tune-away events among others.

Returning to FIG. 1, the illustrated system 100 includes, in addition tothe UEDs 102, a cloud decisioning system (CDS) 106 and a business datamanagement system (BDMS) 108. The BDMS 108 generally collects a varietyof information that is used by the CDS 106 to manage delivery of assetsby the UEDs 102 and provides information useful for billing andanalysis. The CDS 106 and BDMS 108 may be embodied in logic executed onone or more platforms, e.g., web servers, and may run at least in parton the same machines or on different machines. While the CDS 106 isreferred to as a “cloud” decisioning system, and may be implemented as acloud-based system accessed via IP Networks, it will be appreciated thatneither the CDS 106 nor other systems referenced herein are limited to aspecific network environment.

The illustrated BDMS 108 intakes information concerning household tags,break inventory, and orders. The household tag information may includethe classification parameters noted above for each household orindividual members of households. At least the Invidi I, Invidi II,Classifier, Limited Resource, Multicast and Third Party Database casesreferenced above describe systems that distinguish between householdmembers in this regard. The household tag information may also includelocation information associated with the user, such as an address of theuser or current location of the UED 102. This is described at least inthe Location case. This information can be used by the CDS 106 to matchthe UEDs 102 and/or individual users of the UEDs 102 to the targetingconstraints for individual assets (e.g., male, age 21-34, with an incomeof at least $50,000). This information may be obtained from a variety ofsources, including third party databases (such as those of creditagencies such as Experian™) and logic associated with the UEDs 102 andmay be used in combination with information of customer databases ofnetwork providers (e.g., the cable or satellite TV provider).

The break inventory information identifies at least particular upcomingADOs that will be managed by the CDS 106. As noted above, ADOs may bespots in commercial breaks on particular television channels (“assetspots”), product placement opportunities within programming, televisioncrawls or pop-ups, internet/IP advertising or other opportunities. Animportant category of ADOs that can be managed by the CDS 106 in thecontext of television networks is asset spots. In this context, it maybe the case that only certain asset spots are designated by theappropriate stakeholders (e.g., programming networks, local affiliates,etc.) as having assets that may be inserted/replaced, or are otherwiseavailable to be managed by the CDS 106. Those spots may be identified inthe break inventory information. The ADOs identified in the breakinventory information may also include ADOs of, for example, on-demandprogramming. In such cases, the break inventory information may notidentify the ADO by time (which may not be known) but by another indexidentifying the relevant ADO (e.g., it may be known that the on-demandcontent includes three identified breaks, and an ADO of interest may beidentified as the second break). Thus, the break inventory informationmay identify individual ADOs by reference to programs, channels, times,other break indices, etc. Such information may be obtained from datasystems of programming networks, network providers or others.

The order information will generally include information defining assetcampaigns. As further described above and below, as well as at least inthe Invidi I, Invidi II, and Third Party Database applications, suchinformation may relate to delivery constraints such as targetingparameters (e.g., demographics of the target audience), channel orprogram exclusions, proximate asset exclusions, specified channels orprograms, specified times and dates (or ranges thereof), frequency ofdelivery (e.g., how often an asset may be delivered to a particularuser), pacing (at what pace should the total number of impressions befulfilled, e.g., 10 impressions per week), total number of impressions(e.g., how many times an asset may be shown to a particular user),sequencing or other prerequisite information (e.g., asset B should onlybe shown after asset A has been delivered five times, or asset B shouldonly be shown after asset A was delivered/interacted with on theinternet), other contingencies (e.g., show this asset in the event of aparticular outcome of a sporting event or in certain weatherconditions), or other constraints. This information may be obtained atleast in part from a contracting platform where asset providers orothers enter asset delivery requests. Additional information may beobtained from other network platforms and operators having access to therelevant information.

The BDMS 108 may also receive report information from the CDS 106 andoutput information to interested parties. The output report informationmay be the same as the report information received from the CDS 106 ormay be processed, e.g., aggregated, condensed, edited, sorted,supplemented, sanitized in relation to privacy concerns/rights of thereceiving party, and/or selected responsive to a query. The CDS 106receives reports from devices 102 across one or more networks related toasset delivery. As set forth herein and at least in the Invidi I, InvidiII, Asset Skipping, and RFI cases, such reports may indicate what assetwas delivered and for what ADO was delivered (e.g., channel and time),and may also provide information concerning incomplete deliveries (e.g.,asset skips, tune-aways, mutes, etc.), user presence and engagement,active engagement (e.g., requests for information or clicks), subsequentpurchasing behavior, or the like. The CDS 106 may aggregate thisinformation, combine this information with other data (e.g., subsequentpurchasing data, network data, or click stream analysis data) orotherwise process the data before forwarding report information to theBDMS 108.

The reports provided to the CDS 106 and output by the BDMS 108 may beused for a variety of purposes. For example, the reports may be used todetermine the total number of impressions delivered, and the break-downof impressions for different channels and breaks, for purposes ofbilling asset providers and sharing revenues. In addition, the reportsmay be used to determine the extent to which different asset deliveryrequests have been fulfilled so as to inform subsequent deliverydecisions by the CDS 106. The reports including, for example, the numberof asset skips and tune-aways, may be provided to asset providers andothers to analyze asset effectiveness. In this regard, audienceclassification information, for particular users or aggregated, may beprovided with the reports so that the recipient can determine what typesof users skipped assets or tuned-away. The reports may also be providedto various other researchers interested in behavior patterns of networkusers.

As will be appreciated from the foregoing discussion, the CDS 106 isoperative to make decisions concerning what assets will be delivered atthe UEDs 102, 104 in connection with ADOs. FIG. 1 illustrates anexemplary network architecture where the CDS 106 is independent of thenetwork insertion and delivery equipment. In particular, the broadcastcontent stream is delivered to the UED 102 by a digital contentmanagement (DCM) system 110 and certain assets are separately deliveredto the UED 102 by the asset download network (ADN) 112. Neither the DCM110 nor the ADN 112 is directly controlled by the CDS 106 in theillustrated system 100, nor is the CDS 106 dependent upon the specificidentification of the DCM 110 and ADN 112. As will be discussed below,this allows the CDS 106 to remain independent of the network of the UED102 such that the CDS 106 can operate across networks.

In the case of the illustrated broadcast television network, thebroadcast content stream may include multiplexed television channels,delivered by cable or satellite, and assets. In the latter regard, forexample, only certain asset spots on certain channels may be designatedfor replacement with assets as controlled by the CDS 106. Those spotsmay be identified by cue messages inserted into the broadcast contentstream signifying to the UED 102 that an ADO is coming. Such cues may beprovided shortly before, e.g., a few seconds or less prior to, the spotat issue. The remaining spots generally would not be identified by cuemessages and would be indistinguishable from the surrounding programmingstream from the perspective of the UEDs 102. Even the spots identifiedby cue messages as being available for asset insertion at the UEDs 102may have default assets included in the broadcast content stream formore efficient bandwidth usage and reduced processing (e.g., an assetexpected to be appropriate for a large segment of the audience may beselected as the default asset so that device implemented assetsubstitution is minimized).

The DCM 110 may be embodied in satellite network or cable networkdistribution platforms such as headend equipment, node equipment or thelike. The DCM 110 receives the broadcast content from various sourcesand multiplexes the content for transmission to the UEDs 102. The DCM110 also includes the noted cue messages in the broadcast contentstream. In this regard, the DCM 110 receives information identifying therelevant ADOs from the break data server 114. For example, suchinformation may identify specific spots on specific channels that areavailable for asset replacement under control of the CDS 106. The breakdata server 114 obtains inventory information from the BDMS 108concerning these ADOs.

The ADN 112 has access to stored assets that can be downloaded to theUEDs 102. For example, the ADN 112 may store media files for all assetoptions that may be delivered by the UEDs 102. Those files may beprovided, for example, by asset providers or agents thereof. In responseto a request from a UED 102, for example, including identifiers fordesignated assets, appropriate media files may be downloaded to the UED102 for storage in storage until 103 of the UED 102. The ADN 112 may beembodied in one or more servers that communicate with the UEDs 102 via adata network such as the internet.

In operation, the BDMS 108, from time-to-time, sends updated householdtag, orders and inventory information to the CDS 106. This may be doneperiodically, otherwise on a scheduled basis, as updates occur, or onanother basis. Based on this information, the CDS 106, in theillustrated system 100, instructs the UEDs 102 as to what assets tostore. For example, in a multi-member household, the CDS 106 may comparetag information for each household member to targeting constraints foreach asset (as indicated by the orders information) to identify a listof assets that may be played at the UED 102. Such lists may be forwardedto the UEDs 102 on a periodic or other basis, and used by the UEDs 102to select assets to be stored for potential playback at a later time.The assets may be identified in the list by codes or other identifiersadequate to identify the assets.

The manner of storing the assets at the UED 102 can vary depending onthe network implementation. For example, if assets are transmitted tothe UEDs via a broadcast protocol, it may by convenient to transmit allassets to all UEDs 102 within a given network subdivision and theninstruct each UED 102 to only store assets on its list and discardothers to save storage space. The illustrated IP-based system isadvantageous in that each UED 102 can request and receive, from the ADN112, only the assets on its list. It should be noted that, whileconvenient and practical, it is not necessary that the assets beprovided ahead of time and stored versus being transmitted in real-timeat an ADO. Assets may be transmitted at play time where bandwidth andprocessing capabilities allow.

However, in the illustrated implementation where assets are provided tothe UEDs 102 ahead of time, the operation of the system 100 proceeds byhaving the UED 102 request a playlist. In this regard, the playlist maybe different from the list of assets to store for a number of reasons.First, the CDS 106, which may be independent of broadcast network, doesnot necessarily receive and forward to the UEDs 102 all information foreach asset concerning asset delivery constraints, e.g., targetingconstraints, network and programming constraints, etc. Accordingly,while the UED 102 has assets available, it does not necessarily knowwhat assets are appropriate for a given UED. Moreover, in a multiplemember household where assets are stored for different householdmembers, the UED 102 may not know which member or members are presentfor receiving assets. That is, depending on the implementation, the UED102 may or may not have logic for determining which users are present.If it does, this information may be provided to the CDS 106 or maypotentially be used for at least partially autonomous asset selection bythe CDS 106. The illustrated implementation, however, allows fordelivery of addressable assets, including delivery of individuallytargeted assets in a multimember household, without requiring logic atthe UED 102 for identification of a current user. Such identificationmay be performed by the CDS 106 based on the household tag information.

The illustrated CDS 106 also does not necessarily know when an ADO isabout to occur at the UED 102. The CDS 106 does not necessarily know ifthe UED 102 is turned on, what channel it is turned to and, even if ithad access to such information, does not necessarily know when breakswill occur or what spots are available for asset replacement. Moreover,though the illustrated CDS 106 has instructed the UED 102 as to whatassets to store, the CDS 106 does not necessarily know what assets areavailable to be played at the UED 102. The UED 102 may not yet havestored the assets as instructed, the assets may have subsequently beendeleted for various reasons (e.g., change in household composition,changes in constraints or preferences, storage limitations, etc.), orthe assets may otherwise be unavailable for the ADO at issue.

Accordingly, in the illustrated implementation, the UED 102 informs theCDS 106 what assets are available and requests a playlist. This may bedone in a single message between the UED 102 and the CDS 106 or inseparate messages. For example, the assets available may be updatedcontinually as assets and stored or deleted. However, in oneimplementation, the UED 102 reports what assets are available at thesame time as it requests a playlist. The request may be for a singleADO, a set of related ADOs, or otherwise for multiple ADOs. Preferably,the request is for a single or small set of ADOs and is made close intime, e.g., seconds or fractions or seconds, before the beginning of theADO. It will be appreciated that requests made close to the time of theADO are most useful due to channel changes, the potential that the UED102 will be powered off, etc.

The request may include, in addition to identifying what assets areavailable at the UED 102, information identifying the ADO. For example,the information may be sufficient to enable the CDS 106 to select assetstaking into account any delivery constraints (e.g., program or channelinclusions/exclusions) and campaign information (e.g., frequency andoverall impression count). It will be appreciated that monitoring ofinformation related to asset selection decisions could be distributed invarious manners between the CDS 106 and the UEDs 102 (e.g., the UEDs 102could count total number of impressions delivered for an asset). In theillustrated implementation, substantially all aspects of monitoring anddecision-making are executed at the CDS 106. This reduces the need forspecialized logic/resources at the UEDs 102, allows the system 100 to bedeployed without upgrading the UEDs 102, and allows the CDS 106 tooperate independent of the specific attributes of the UEDs 102 whichfacilitates operation across all UEDs of a network and across networks.

The CDS 106 then provides a list of one or more assets to play at one ormore ADOs. In the simplest case, this may be an instruction to play aspecific asset (e.g., identified by a code or other identifier) at theimmediately ensuing ADO. However, it is also possible for the playlistto include alternate assets for different channels/ADOs (e.g., in caseof channel change) or alternate assets for a single ADO, or parametersfor controlling the UED 102 to select the asset. In any case, the UED102 plays an asset from the storage unit 103 response to receiving theplaylist. For example, the UED 102 may commence playback from storage103 based on a detected cue message in the broadcast stream.

The UED 102 and/or CDS 106 may then monitor delivery of the asset at theUED 102. It is possible to implement the system 100 such that, onceasset delivery begins, it continues regardless of channel charges,fast-forward commands (e.g., in the case of on-demand or time-shiftedcontexts) or the like. However, in one implementation, the UED 102monitors asset skips or time-aways. The UED 102 or CDS 106 may alsomonitor other information such as user presence and engagement, muting,volume, any requests for information entered in relation to an asset orthe like. Some or all of this information may be provided in a reportsent from the UED 102 to the CDS 106. Such reporting is described atleast in the Invidi I, Invidi II, and Asset Skipping cases. For example,a report may include, for each ADO, an identification of the assetdelivered, an indication of the time of delivery, an indication of thechannel or program in connection with which asset was delivered and,optionality, additional information such as completeness of assetdelivery and presence/engagement information. These reports may be sentfor each ADO or aggregated for periodic transmission. Moreover, thereports may be collected for each ADO for each UED 102, or a statisticalreporting process may be implemented. In turn, the CDS 106 may providereport information based on the reports from the UEDs 102 to interestedparties as described above.

While much of the preceding discussion has focused on asset delivery inthe context of linear, broadcast content. It will be appreciated thatthe system 100 is applicable in other contexts such as on-demand,time-shifted playback at the UED 102, linear to on-demand, streaming,etc. In any such contexts, ADOs can be detected by the UED 102 based oncue messages or other means. Assets (in the appropriate format) can bestored and delivered as described above, including playlist requests,reports, etc. Again, as the CDS 106 need not be integrated into thecontext delivery systems, much of the functionality is independent ofthe ADO context.

FIGS. 2-3 illustrate alternative systems 200, 300 for implementingaddressable asset delivery where asset delivery can be managed acrossmultiple UEDs 202, 204 and 302, 304. Although two UEDs 202, 204 and 302,304 are shown in each case, delivery of assets can be managed acrosssubstantially any number of UEDs subject to practical limitations. TheUEDs 202, 204 and 302, 304 may be the same or different, may be in thesame location or different locations, and may be part of the samenetwork or different networks. The present embodiments focus on the casewhere the UEDs 202, 204 and 302, 304 are in the same location and arepart of the same network, e.g., different televisions in the sameresidence. It will be appreciated that this is an important case as auser may receive assets via different televisions within a household andit may be useful to manage asset delivery, including frequency and totalnumber of impressions, across those devices.

The structure and functionality of the systems 200, 300 can besubstantially the same as described above in connection with FIG. 1except for the structure and functionality specific to multiple devices.In this regard, the systems 200, 300 include BDMSs 208, 308, CDSs 206,306, break data servers 214, 314, DCMs 210, 310, and ADNs 212, 312, allsubstantially as described above.

The principal difference between the systems 200, 300 of FIGS. 2 and 3is that the UEDs 302, 304 of FIG. 3 are each depicted as having assetstorage units 303, 305 whereas the UEDs 202, 204 of FIG. 2 do not. Thereare a number of contexts where assets may not be stored locally on eachUED 202, 204. For example, storage may be provided by a single, optionalsite controller unit 213 that is networked to the UEDs 202, 204. Forexample, the site controller 213 may be located at the same location asthe UEDs 202, 204 (e.g., at the same residence) or at another locationand may be embodied as an external storage unit, a master set top box,or the like. Local storage at each device 202, 204 also may not benecessary in on-demand contexts (e.g., if the CDS 206 directs theon-demand platform to insert assets) or where replacement assets aredelivered by the ADN 212 in real-time. It will be appreciated that, incontexts where the UEDs 202, 204 do not have local storage units, theUEDs 202, 204 will not receive a list of assets to store (though a sitecontroller 213 may get a corresponding list applicable to the UEDs 202and 204). The UEDs 202, 204 may still request playlists and providereports.

There are a number of housekeeping functions that can be addressed tomanage asset delivery across multiple UEDs 202, 204 or 302, 304. First,the CDS 206, 306 can maintain lists of related UEDs 202, 204 and 302,304, e.g., lists of devices designated for collective management. Inthis regard, each UED 202, 204 and 302, 304 can be identified by a MACaddress or other identifier and those identifiers can be used to compilethe lists and used in communications (e.g., playlist requests, reports,etc.). In cases where asset delivery is managed for multiple individualsassociated with one or more devices, individuals may also haveidentifiers for use by the CDSs 206, 306 (this would also be the caseeven for managing a single device). The individuals may be identified bythe CDSs 206, 306, e.g., based on the household tags and network usageinformation, and will not necessarily need to be identified in playlistrequests, reports, etc.

In any case, asset deliveries or partial deliveries on either device202, 204 or 302, 304 can be reported to the CDS 206, 306 and recordedagainst the collectively managed entity defined in terms of a user orusers and multiple devices. For example, if a given user received anasset three times via UED 202 and two times via UED 204, the CDS 206 mayrecord that the user has received the asset five times. Thesecollectively analyzed reports can be used to manage compliance withcampaign specifications such as frequency and total number ofimpressions.

FIG. 4 illustrates and addressable advertising system 400 that can beused to manage delivery of assets across multiple devices and multiplenetworks. The illustrated system 400 includes a cloud-based decisioningsystem (CDS) 402 that manages decision making for asset delivery acrossmultiple UEDs. The illustrated CDS 402 receives information from avariety of sources including a third-party database 404 and a campaigninformation platform 406 and can provide output information to ananalytics processing platform 408. The CDS 402, in turn, controls assetdelivery with respect to UEDs in multiple networks 410-412.

The third-party database 404 can provide a variety of information thatis useful in targeting assets to particular subscribers and evaluatingthe effectiveness of assets. For example, the third-party database 404can be accessed to obtain demographics information, income information,purchasing behavior information or the like for individuals andhouseholds. This information may be indexed to a residence address or anidentification of an individual. This information may be used inconnection with network information 414, 426, 440 from the networks410-412 to correlate the information from the third-party database 404with particular users or households of the networks 410-412.

The information from the third-party database 404 may be used to matchindividual users or households to targeting constraints of assets, or totrack activities subsequent to asset delivery to analyze asseteffectiveness. For example, information concerning income, brands ofproducts purchased, age, gender, data network behavior, occupation orthe like may be used to match users or households to targetingconstraints of assets prior to asset delivery. Information from thethird-party database 404 concerning purchasing decisions, websitevisits, or other behavior may be used to track asset effectiveness afterdelivery.

Although a single third-party database 404 is shown for purposes ofillustration, such information may be obtained from multiple datasources associated with multiple entities. Examples include creditagencies like Experian™, sources of website traffic data, loyaltyprograms of retail outlets, and other customer information databases.For example, an asset provider, such as Ford Motor Company, may seek totarget assets to current Ford owners on the networks 410-412. Deliveryof the assets on the networks 410-412 may then be tracked to achieve adesired level of campaign fulfillment. Thereafter, behavior of thenetwork users may be tracked via the third-party database 404 todetermine how many users of the networks 410-412 who receive the assetin question purchased Ford products or third-party products. In thismanner, asset delivery across the networks 410-412 is precisely targetedand tracked, and subsequent behavior is analyzed to close the loopconcerning asset effectiveness.

The CDS 402 also receives campaign information 406 regarding campaignsfor various assets. As discussed above, campaign information may includetargeting constraints defining the targeted audience as well as campaignconstraints defining various parameters of a campaign such as the daterange of the campaign, the desired networks or programming associationsof the asset, the frequency of asset delivery, pacing, and the totalnumber of impressions to be delivered. In the context of the illustratedsystem 400, such campaign information may also define campaignconstraints specific to the multi-network environment. For example, thecampaign information 406 may specify that, for example, a broadcastnetwork asset should only be delivered after a particular user hasreceived an internet asset, or that a particular user should receive aninternet asset a certain number of times, a wireless asset a certainnumber of times and a broadcast network asset a certain number of times.The CDS 402 is operative to monitor such deliveries across networks toensure campaign fulfillment.

The analytics processing platform 408 can receive information related toasset delivery for a variety of purposes such as billing, revenuesplitting and analysis of asset effectiveness. In this regard, the CDS402 can provide information to the analytics processing platform 408periodically or in response to queries. For purposes of billing andrevenue splitting, the information provided by the CDS 402 to theanalytics processing platform 408 may include total number ofimpressions, an identification of the networks for which impressionswere delivered, an indication of channels, websites, or otherassociations, or any other information relevant to billing and revenuesharing. In the case of analytics processing for asset effectiveness,the platform 408 may query the CDS 402 to obtain a variety ofinformation related to a particular asset or set of assets. Appropriatesecurity protocols may be implemented to ensure privacy and to ensurethat information is only accessed by authorized parties.

As noted above, the CDS 402 can manage and monitor asset delivery acrossmultiple networks 410-412. Many different types of networks may bemanaged and monitored in this regard. For purposes of illustration, FIG.4 shows three networks; a data network 410, a broadcast network 411, anda wireless network 412. For example, the data network 410 may includecomputers 416, servers 418, and tablets 420 among other types of dataterminals. The broadcast network 411 may include Smart TVs 428, TVs 430associated with set-top boxes 432, headend equipment 422, and videoon-demand equipment 424. The CDS 402 may communicate with any of thesecomponents to control and monitor asset delivery in the network 411.

The illustrated wireless network 412 may include cell cites 434, tablets436, and telephones 438. The CDS 402 may also communicate with awireless location platform of the network 412 or separate therefrom inorder to obtain information concerning the locations of wireless units.

It will be appreciated that the same asset may be delivered across anyof the networks 410-412. For example, a full video asset may be insertedinto a broadcast content stream or delivered via streaming in the datanetwork 410 or wireless network 412. In addition, related assets may bedelivered via the various networks 410-412. For example, an assetprovider may provide three related assets including a full video assetfor delivery in the broadcast network 411, a panel asset for deliveryvia the data network 410, and a mobile unit optimized asset for deliveryvia the wireless network 412. The CDS 402 can recognize the appropriateasset based on the identification of the UED submitting a playlistrequest. The illustrated system 400 thus allows for management of asingle campaign across multiple networks 410-412. In addition, theillustrated system 400 facilitates operation of a single contractingplatform to reach multiple networks 410-412.

FIG. 5 is a flow chart illustrating a process 500 for managing andmonitoring asset delivery in accordance with the present invention. Theillustrated process 500 is initiated by receiving (502) campaigninformation defining a campaign for delivery of an asset or a set ofassets. For example, the campaign information may be entered via one ormore contracting platforms. In a preferred implementation, a singlecontracting platform can be utilized to enter information defining asingle campaign extending across multiple networks.

A cloud decisioning system as described above can receive this campaigninformation as well as receiving (504) household information. Thehousehold information provides information concerning a household orindividuals within a household that can be used to match households orindividuals to the targeting constraints of an asset. As describedabove, this may include demographics, income information, purchasingbehavior and the like. The CDS may also receive (506) impressioninformation for an asset. For example, the CDS may receive reports fromUEDs. These reports may indicate that an asset was delivered orpartially delivered to a particular individual, household, UED, or typeof UED. This information may be used by the CDS to determine a level offulfillment of a campaign and, therefore, whether the asset remainsavailable for delivery to a given UED or user.

The CDS may also receive (508) inventory information. Such inventoryinformation may relate to, for example, the ADOs that are available forasset replacement or insertion. In the context of a broadcast televisionnetwork, the inventory information may identify particular spots onparticular programming networks where assets may be substituted into thebroadcasting content stream. In the context of data networks or wirelessnetworks, the asset delivery opportunities may relate to placement ofvideo assets in streaming content, image-based assets on web pages, orother ADOs.

In certain implementations, the CDS may direct (510) the UED to storeassets in advance of an ADO. As discussed above, storage unitsassociated with particular UEDs or households in a broadcast televisionnetwork may store assets that may be delivered in subsequent ADOs.Similarly, UEDs in data and wireless networks may be directed to storeassets that will later be placed into asset placement spots of webpagesor other content. In certain implementations, the CDS may occasionallyreceive and update (512) a list of assets that are available to beplayed at the UED. For example, as described above, individual UEDs of abroadcast television network may report to the CDS what assets areavailable to be played at the time that a playlist is requested. The CDSthen receives (514) notice of an ADO. In this regard, a UED may contactthe CDS to request a playlist for an upcoming ADO or set of ADOs. Inrespond, the CDS may direct (516) the UED to deliver a specified asset.For example, the CDS may provide a playlist to the UED identifying oneor more assets to be played in connection with one or more ADOs. Afterone or more assets have been delivered by the UED, the UED may provideand the CDS may receive (518) a report concerning asset delivery. Thereport may indicate the asset that was delivered, the time of delivery,whether delivery was complete, what channel, website or other contentthe asset was delivered in connection with, and the like. The CDS canthen update (512) impression information for the particular asset andfor the particular user or UED that delivered the asset. The updatedimpression information can then be used to evaluate fulfilment of theasset campaign.

The implementations as described above in connection with the variousembodiments can be used to support a number of use cases. A number ofthese use cases are set forth below for purposes of illustration. Itwill be appreciated that many other use cases are possible in accordancewith the present invention.

The first use case, and perhaps the simplest use case, relates tomanaging and monitoring asset delivery via a single UED of a singlenetwork. This generally corresponds to the system shown in FIG. 1 above.In this case, the UED notifies the CDS of an upcoming ADO. In response,this CDS provides a playlist identifying an asset to be delivered inconnection with the ADO. The UED then delivers the asset and reportsdelivery to the CDS. The CDS can track delivery based on the reports todetermine a level of fulfilment of a campaign. While other architecturescould be employed to track asset delivery, it will be appreciated thatthe noted architecture enables the CDS to manage and monitor assetdelivery independent of the content delivery networks.

A second use case relates to managing and monitoring asset deliveryacross multiple devices of a single network. This generally correspondsto the embodiments described in connection with FIGS. 2-3 above. Forexample, this is useful to track delivery of assets to a singleindividual who used multiple UEDs in a single network, e.g., multipletelevisions in a single household or multiple households of a network.In this case, the CDS can use stored information concerningrelationships between UEDs and/or report information to determinecollective information concerning impressions delivered via differentUEDs of the network. For example, if a given user receives an assetthree times on a first UED and two times on a second UED, the CDS canproperly track that the user has received the asset a total of fivetimes. Similarly, if each report includes time of delivery information,the CDS can ensure that the user receives the asset on different UEDsonly in compliance with frequency constraints.

The system can also manage and monitor asset delivery across multipleUEDs of multiple networks. In this regard, for example, the CDS mayidentify deliveries of an asset to an individual on different UEDs indifferent networks (including assets delivered at the same or atoverlapping times, e.g., in a two screen consumption context such assimultaneous television and tablet use) based on stored informationrelating the UEDs and/or report information. In this manner, impressionsdelivered on the different UEDs of the different networks to a singleuser may be combined to ensure compliance with campaign constraints. Forexample, in the case of TV Anywhere programs, the CDS may determine thata user has received an asset twice in linear television programming andonce more during program streaming on a tablet or laptop computer.Accordingly, the CDS may determine that the user has received threeimpressions for the asset. Similarly, the CDS may determine that a userhas received an asset twice during linear television programming andonce more via streaming in an unrelated network. Again, the CDS cancombine these impressions to ensure compliance with campaignconstraints.

The system can also be used to manage compliance with certain sequencingconstraints concerning an asset or set of related assets. For example,an asset provider may specify that a first asset should be viewed acertain number of times, then a second asset should be delivered acertain number of times and then a third asset should be delivered acertain number of times. Asset delivery can be monitored by the notedsystem to ensure that the desired sequence is implemented.

As a further example, an asset provider may specify that a certain assetshould only be delivered to television viewers after a related, teaserasset has been delivered during an internet session or vice versa. Thenoted system can monitor asset delivery across networks to ensure theproper sequencing.

The foregoing description of the present invention has been presentedfor purposed of illustration and description. Furthermore, thedescription is not intended to limit the invention to the form disclosedherein. Consequently, variations and modifications commensurate with theabove teachings, and skill and knowledge of the relevant art are withinthe scope of the present invention. The embodiments described hereinabove are further intended to explain best modes known of practicing theinvention and to enable others skilled in the art to utilize theinvention in such or other embodiments and with various modificationsrequired by the particular application(s) or use(s) of the presentinvention. It is intended that the appended claims be construed toinclude alternative embodiments to the extent permitted by the priorart.

What is claimed is:
 1. A method of delivering assets to subscribersusing communication media, wherein each subscriber has a user equipmentdevice (UED) remote from and in operative communication with an assetdecisioning system, the method comprising the steps of: establishing, atthe asset decisioning system, information regarding an asset set, theasset set including one or more assets for scheduling for delivery toparticular subscribers, the asset set established at least partiallybased on campaign specification information for each asset of the assetset; instructing a UED associated with one of the subscribers to storeassets of the asset set at a memory structure of the UED based onsubscriber impression information, wherein the subscriber impressioninformation represents a level of fulfillment of the campaignspecification information for a respective asset of the asset set inrelation to the subscriber; and transmitting, in response to anidentified asset delivery opportunity, a playlist to the UED thatinstructs the UED to playback one or more assets of the stored assetswithin the identified asset delivery opportunity.
 2. The method of claim1, further comprising: obtaining audience feedback information from theUED indicative of subscriber interaction with the UED during assetplayback.
 3. The method of claim 2, wherein the subscriber interaction,in relation to at least one asset associated with the playlist, includesasset playback speed, asset playback volume, and asset playback runtime.4. The method of claim 2, further comprising: reporting the audiencefeedback information.
 5. The method of claim 1, wherein the assetdecisioning system is operative to: obtain, from asset providers,decisioning information for assets, the decisioning informationidentifying target audiences for the assets; and obtain audienceclassification information for subscribers, the audience classificationinformation including at least one classification parameter of thesubscriber.
 6. The method of claim 5, wherein the classificationparameter relates to at least one of age, gender, income level, personalinterest, or locale of the subscriber.
 7. The method of claim 5, whereinthe asset set comprises assets for which the corresponding decisioninginformation matches the audience classification information of thesubscriber.
 8. The method of claim 5, wherein each asset of the assetset is associated with an asset delivery request received by the assetdecisioning system, each asset delivery request indicative of a requestto deliver a corresponding asset to the subscriber.
 9. The method ofclaim 8, wherein the stored assets include assets delivered via acomputer-based content exchange remote from the asset decisioningsystem.
 10. The method of claim 9, wherein the computer-based contentexchange delivers assets to the UED at least partially based on at leastone asset delivery request associated with an asset of the asset set.11. The method of claim 9, wherein the computer-based content exchangecomprises an IP-based data network.
 12. The method of claim 1, whereinthe asset set is established in relation to the identified assetdelivery opportunity.
 13. The method of claim 1, wherein the indicationindicative of the stored assets corresponds to the identified assetdelivery opportunity.
 14. The method of claim 1, wherein the identifiedasset delivery opportunity comprises a unique opportunity to deliver theone or more assets into a designated spot of designated programing tothe subscriber.
 15. The method of claim 1, further comprising: receivingan indication indicative of a time of delivery by the UED of at leastone asset associated with the playlist; and based on the receiving,updating the subscriber impression information for the at least oneasset associated with the playlist.
 16. The method of claim 15, whereinthe campaign specification information includes a frequency of deliveryparameter, the frequency of delivery parameter indicative of a maximumimpression count corresponding to a number of instances the subscriberviews assets of the asset set.
 17. The method of claim 16, wherein thecampaign specification information includes a minimum time intervalparameter, the minimum time interval parameter indicative of a minimumtime period between the instances of the subscriber viewing the firstasset within the identified period.
 18. A communication system fordelivering decisioning assets to subscribers using communication media,wherein each subscriber has a user equipment device (UED) remote fromand in operative communication with an asset decisioning system, thesystem comprising: a processor-based asset decisioning system havinglogic for establishing an asset set, the asset set including one or moreassets for scheduling for delivery to particular subscribers andestablished at least partially based on campaign specificationinformation for each asset of the asset set; a communication moduleconfigured to: instruct a UED associated with one of the subscribers tostore assets of the asset set at a memory structure of the UED based onsubscriber impression information, wherein the subscriber impressioninformation represents a level of fulfillment of the campaignspecification information for a respective asset of the asset set inrelation to the subscriber; and transmit, in response to an identifiedasset delivery opportunity, a playlist to the UED that instructs the UEDto playback one or more assets of the stored asset within the identifiedasset delivery opportunity.
 19. The system of claim 18, wherein theprocessor-based asset decisioning system is operative to obtain audiencefeedback information form the UED indicative of subscriber interactionwith the UED during asset playback.
 20. The system of claim 19, whereinthe subscriber interaction, in relation to at least one asset associatedwith the playlist, includes asset playback speed, asset playback volume,and asset playback runtime.
 21. The system of claim 19, wherein thecommunication module is further configured to: report the audiencefeedback information.
 22. The system of claim 18, wherein the assetdecisioning system is operative to: obtain, from asset providers,decisioning information for assets, the decisioning informationidentifying target audiences for the assets; and obtain audienceclassification information for subscribers, the audience classificationinformation including at least one classification parameter of thesubscriber.
 23. The system of claim 22, wherein the classificationparameter relates to at least one of age, gender, income level, personalinterest, or locale of the subscriber.
 24. The system of claim 22,wherein the asset set comprises assets for which the correspondingdecisioning information matches the audience classification informationof the subscriber.
 25. The system of claim 22, wherein each asset of theasset set is associated with an asset delivery request by the assetdecisioning system, each asset delivery request indicative of a requestto deliver a corresponding asset to the subscriber.
 26. The system ofclaim 25, wherein the stored assets include assets delivered via acomputer-based content exchange remote from the asset decisioningsystem.
 27. The system of claim 26, wherein the computer-based contentexchange delivers assets to the UED at least partially based on at leastone asset delivery request associated with an asset of the asset set.28. The system of claim 26, wherein the computer-based content exchangecomprises an IP-based data network.
 29. The system of claim 18, whereinthe asset set is established in relation to the identified assetdelivery opportunity.
 30. The system of claim 18, wherein the indicationindicative of the stored assets corresponds to the identified assetdelivery opportunity.
 31. The system of claim 18, wherein the identifiedasset delivery opportunity comprises a unique opportunity to deliver theone or more assets into a designated spot of designated programming tothe subscriber.
 32. The system of claim 18, wherein the processor-basedasset decisioning system is operative to: receive an indicationindicative of a time of delivery by the UED of at least one assetassociated with the playlist; and based on the received indication,update the subscriber impression information for the at least one assetassociated with the playlist.
 33. The system of claim 32, wherein thecampaign specification information includes a frequency of deliveryparameter, the frequency of delivery parameter indicative of a maximumimpression count corresponding to a number of instances the subscriberviews the assets of the asset set.
 34. The system of claim 33, whereinthe campaign specification information includes a minimum time intervalparameter, the minimum time interval parameter indicative of a minimumtime period between the instances of the subscriber viewing the firstasset within the identified period.